PowerShell in SQL Server 2008

Adding PowerShell Support

Either during the initial installation of SQL 2008 or afterward while changing the installed features, you are able to add the SQL Server–specific PowerShell features by using the setup utility. The Management Tools-Basic feature must be added, as shown in Figure 1.

Figure 1. Installing the PowerShell features.

The Management Studio add-on is also required to get the PowerShell-specific features installed. This specific feature adds the following:

• Management Studio— The graphical user interface for managing SQL Server 2008

• SQLCMD— The utility that SQL scripters should already be familiar with

• SQL Server PowerShell provider— The PowerShell-specific extra functionality

Accessing PowerShell

Now that you have added the SQL Server–specific PowerShell features, you can access a SQL Server PowerShell session.

SQL Server PowerShell can be accessed in either of two ways:

• You can open SQL Server PowerShell via the SQL Server Management Studio by right-clicking on a particular object in the Object Explorer and selecting Start PowerShell, as shown in Figure 2. This way is handy because it provides a prompt in the SQL provider (which is discussed shortly) in the location of the object that was right-clicked.

  Figure 2. Accessing PowerShell via SSMS.

  

• You also can open SQL Server PowerShell directly from regular DOS or a regular PowerShell console by simply navigating to the appropriate location, as shown in Figure 3.

  Figure 3. Accessing PowerShell using sqlps.exe.

  

SQL Server PowerShell

When you first get into SQL Server PowerShell, you might notice that this is a restricted version of the default PowerShell console. In other words, several of the core cmdlets are not available in SQL Server PowerShell, and others might not work exactly the same way. For example, invoking the Get-Command cmdlet alone with no other arguments does not list all the available commands.

Get-Command : Object reference not set to an instance of an object.

PS SQLSERVER:\> cd c:\
PS C:\> Get-Command
  <output deleted>
PS C:\> cd SQLSERVER:
PS SQLSERVER:\>

The term provider was briefly introduced. The SQL team decided to implement a SQL Server provider. What this provides is a layout of the SQL object structure, which resembles that of a regular file system.

You use the SQL provider when accessing SQL Server PowerShell via SQL Server Management Studio: depending on what object you right-click to access SQL Server PowerShell, a prompt opens in the context of that particular object. Basically, the way certain commands work is also affected by the current location within the SQL Server provider. Here are two different examples of being placed in different locations within the SQL Server provider. In the first example, the AdventureWorks2008R2 database was right-clicked within SSMS, as shown in Figure 4. In the second example, a specific table (Person.Address) within the AdventureWorks2008R2 database was right-clicked, as shown in Figure 5.

Figure 4. SQL Server provider at the database level.

Figure 5. SQL Server provider at the table level.

When you start the SQL Server PowerShell minishell by simply invoking sqlps.exe as seen earlier, a prompt opens at the root of the SQL Server provider.

A number of cmdlets available in SQL Server PowerShell are part of the basic PowerShell functionality. However, within SQL Server PowerShell, five additional cmdlets are available only after the minishell is started (or if the snap-in is loaded manually, which is not covered in any detail here):

• Invoke-PolicyEvaluation— A cmdlet that evaluates a SQL Server Policy-Based Management policy (or policies) against a target server.

• Invoke-SqlCmd— A cmdlet that runs any regular T-SQL command and any languages and commands supported by the sqlcmd utility, which may be more familiar to most users.

• Encode-SqlName— A cmdlet that helps to encode SQL Server identifiers into a format that PowerShell can use.

• Decode-SqlName— A cmdlet that helps to return the original SQL Server identifiers from a value previously given by the Encode-SqlName cmdlet.

• Convert-UrnToPath— A cmdlet that converts the SMO Uniform Resource Name to a SQL Server provider path.

Later, examples of using the core cmdlets are provided, as well as the first two cmdlets introduced in the preceding list.

SQL Server Agent Support

PowerShell has been integrated into the SQL Server Agent subsystem. In other words, you can create jobs that call PowerShell-specific commands to run.